1. Field of the Invention
This invention relates to digital interface design, and more particularly, to bus interface design.
1. Description of the Related Art
Interrupts provide principal functionality in many computer systems. Generally, interrupts comprise asynchronous hardware signals and/or software flags indicating when respective subsystems or routines require attention. A hardware interrupt to a processor or a master controller typically causes the processor or controller to save its current execution state, and begin executing an interrupt handler. A software interrupt typically comprises instructions in an instruction set, configured to enable a context switch to the interrupt handler in a manner similar to that of a hardware interrupt. In general, interrupts provide a means to eliminate the need for a processor to use polling loops for checking/waiting for external events, by signaling the processor that an event has occurred, all the while the processor carries on executing other tasks while that event is pending.
Interrupts may be implemented in hardware with control lines, otherwise known as interrupt lines, or they may be integrated into memory subsystems, and fall into a variety of categories. Examples of interrupts include software interrupt, interprocessor interrupt, maskable interrupt, non-maskable interrupt, and spurious interrupt. Many processors will typically have an internal interrupt mask that, when set, allows software to ignore all external hardware interrupts, which provides faster access than disabling interrupts in the device itself. Sometimes, disabling and enabling interrupts on the processor itself may actually be slower. Interrupts are typically used for system timers, disk Input/Output (I/O), traps, and power-off signals, or to transfer data using various transfer protocols (e.g. Ethernet), and are often also used in type-ahead features for buffering events like keystrokes.
One key issue associated with interrupts is interrupt latency, which indicates the time period from the generation of an interrupt to the servicing of that interrupt. In many operating systems interrupts are serviced as soon as the interrupting device's interrupt handler is executed. Interrupt latency may be affected by a variety of factors, including interrupt controllers, interrupt masking, and the methods by which the operating system responds to and processes the interrupt. There is typically a tradeoff between interrupt latency, throughput, and processor utilization. Many times, design techniques that emphasize improving interrupt latency might decrease throughput and increase processor utilization. Conversely, increasing throughput may increase interrupt latency and processor utilization, while, reducing processor utilization may increase interrupt latency and decrease throughput.
For example, when a computer communicates with a secondary system, such as an Input/Output device, the computer may initiate requests—e.g. reads and writes—as a bus master. In such a system the secondary device may be configured to simply respond to these requests by returning requested data to the computer for a read, or by acknowledging a write operation. If,the secondary system needs to be serviced by the computer, or needs to notify the computer of an event that the secondary system requires the computer to service, the notification will typically occur via the interrupt line, which would be considered an out-of-band signal line. In other words, in such a system, the interrupt line would comprise an additional signal line that is not the signal line, or part of the signal lines, that convey the computer's requests and the secondary device's responses.
FIG. 1 shows a typical master-slave system, in which the master device 102 controls the clock source and provides clock signal 106. The slave device 104 in this configuration does not initiate any transactions. Data for regular transactions is transmitted via bidirectional bus 108. Control interrupts are signaled by the slave device 104 asserting the interrupt signal 110. The master device 102 may read the various status registers to determine the interrupting source. Interrupts may occur during data transactions, and can typically be serviced after a current transaction completes. As part of a response to such interrupts, the master device 102 (e.g. computer or controller) would typically have to make specific read requests to the slave device 104 over bus 108 after it [master device 102] has received the interrupt, in order to gather information about the interrupting event.
Oftentimes, systems may need to limit interconnect wires due to device size or number of I/O pins available on the device. Configuring such systems with requisite interrupt lines may be costly, or even non feasible, despite a need for the system to have interrupt handling capabilities. The removal of an interrupt line in a 2-wire bus interconnection scheme—for example, the removal of line 110 in the system of FIG. 1—may represent potential cost savings by eliminating a pin from both the computer and the secondary device(s).
Many other problems and disadvantages of the prior art will become apparent to one skilled in the art after comparing such prior art with the present invention as described herein.